Nested Projects

I wonder the usefullness of nested projects.  Perhaps folks have other ideas, but so far I see only these reasons:

[1] A top-level "Project" that only houses other Projects, so CPS "Groups" can be used between projects.

[2] A top-level "Project" that only houses other Projects, so inter-project "Links" are supported when the top level project is Archived.

I don't see how a construct of one full project (with folders and modules and links) would be inside some other full project.  Is there a real-world example of one project being both independant and also subordinate to some other project?

-Louie


llandale - Mon Sep 16 09:32:49 EDT 2013

Re: Nested Projects
Pekka_Makinen - Tue Sep 17 10:05:36 EDT 2013

Well, isn't it the real-world situation that large (HUGE) projects are actually composed of many sub-projects? The sub-projects derive their requirements from the upper level project (which is often called a program or such), but they have their own schedules and own personnel implementing them.

For example a project to build a new airport: the airport project has it's requirements, but these are implemented in the sub-projects for runways, airport terminal, radars, air control, rescue service and so on...

Re: Nested Projects
llandale - Tue Sep 17 10:29:01 EDT 2013

Pekka_Makinen - Tue Sep 17 10:05:36 EDT 2013

Well, isn't it the real-world situation that large (HUGE) projects are actually composed of many sub-projects? The sub-projects derive their requirements from the upper level project (which is often called a program or such), but they have their own schedules and own personnel implementing them.

For example a project to build a new airport: the airport project has it's requirements, but these are implemented in the sub-projects for runways, airport terminal, radars, air control, rescue service and so on...

Let me babble out loud.

Your 2nd paragraph doesn't seem right.  The Airport has requirements which are decomposed to Runway (et tal) requirements; but that is all in one project.

I wonder though if a Airport Manufacurer has a standard "Airport" project of requirements and design; but specific towns order Airports with their own custom requirements; thus a particular Town's "Project" could be a sub-set of the overall "Standard" project.  Even so, it really would not need to be nested.   Thinking out loud: the Standard Project really is not composed of the Standard requirements/design, AND Town-A and Town-B's custom projects.  But Town-A's project is indeed composed of it's customzations and the standard project.  Hmmmmm.

Back to 2nd paragraph: Sub-contractor "Runway" cares about the Runway requirements and the Airport requirements but not sub-contractor "Terminal".  Prime contractor "Airport" indeed cares about sub-contractor "Runway" and all other sub-contractor requirements.  So maybe, yes, one WOULD nest in that situation; to hide sibling sub-contractor projects from each other and/or facilitate partiioning etc.  Project nesting simply replaces standard folder nesting.

Hmmmmm.

-Louie

Re: Nested Projects
Dartguru - Wed Sep 18 05:06:17 EDT 2013

I read frequently but post rarely as others have far more experience than I, but I have an interest in this particular thread.

In our scenario, we have a project for which there have been ten variations for different customers which, for security and contractual reasons, have been been kept in completely separate project folders. Each time a new project contract is awarded, a new project folder is created which MAY contain much of what is held in another project folder, then customised for its particular needs, with its own set of modules and test specifications, schedules and results. They all conform to a standard but are unique to each project.

I've now got involved and want to create a generic set of requirements which are common to two or more of the projects.

If I created one overarching Project X which contained nothing but folders for projects A, B, C and so on, I could at the Project X level create a folder "Generic Product Requirements" with those generic requirements and link to requirements in the various projects as desired.

An added consideration is that the various projects A/B/C are run by different teams who may not have visibility of other projects. If everyone could see Project X and the generic folder and its requirements module but I controlled access to each project such that they could only see project(s) relevant to them, how would this be viewed in the generic requirements module? Would they be able to see that there are links to other projects but not be able to access them, or would they be completely hidden from them ?

And, more importantly, is this a sensible approach? I have plenty of experience in projects with many derived requirements for sub-contractors and procurement documents, but this is the first time I've come across a project situation like this.

Re: Nested Projects
llandale - Wed Sep 18 12:58:45 EDT 2013

Dartguru - Wed Sep 18 05:06:17 EDT 2013

I read frequently but post rarely as others have far more experience than I, but I have an interest in this particular thread.

In our scenario, we have a project for which there have been ten variations for different customers which, for security and contractual reasons, have been been kept in completely separate project folders. Each time a new project contract is awarded, a new project folder is created which MAY contain much of what is held in another project folder, then customised for its particular needs, with its own set of modules and test specifications, schedules and results. They all conform to a standard but are unique to each project.

I've now got involved and want to create a generic set of requirements which are common to two or more of the projects.

If I created one overarching Project X which contained nothing but folders for projects A, B, C and so on, I could at the Project X level create a folder "Generic Product Requirements" with those generic requirements and link to requirements in the various projects as desired.

An added consideration is that the various projects A/B/C are run by different teams who may not have visibility of other projects. If everyone could see Project X and the generic folder and its requirements module but I controlled access to each project such that they could only see project(s) relevant to them, how would this be viewed in the generic requirements module? Would they be able to see that there are links to other projects but not be able to access them, or would they be completely hidden from them ?

And, more importantly, is this a sensible approach? I have plenty of experience in projects with many derived requirements for sub-contractors and procurement documents, but this is the first time I've come across a project situation like this.

If you have Read access to the Source but not to the target Object or Module, you will see the Link and I think you CAN determine the module name and target AbsNo; but nothing about that object.

I don't think you should be linking between your specific projects.

If you have the over-all generic Project X then the individual specific project's would link to that; and I'd see no reason to "Link" to other Specific Projects.  I like this approach; so long as the Specific projects define what is DIFFERENT from the Generic Project.

-Louie

Re: Nested Projects
Dartguru - Thu Sep 26 07:16:07 EDT 2013

llandale - Wed Sep 18 12:58:45 EDT 2013

If you have Read access to the Source but not to the target Object or Module, you will see the Link and I think you CAN determine the module name and target AbsNo; but nothing about that object.

I don't think you should be linking between your specific projects.

If you have the over-all generic Project X then the individual specific project's would link to that; and I'd see no reason to "Link" to other Specific Projects.  I like this approach; so long as the Specific projects define what is DIFFERENT from the Generic Project.

-Louie

So I'd be looking at:-

Project X - contains Generic Product Requirements (GPR) module(s) (either at the same level or within a GPR folder), and folders for projects A,B,C and so on.

I could copy GPR requirements to any of project A,B,C etc linked back to the GPR original. It may be that the GPR requirement I have copied is only a "starting point" and the project itself derives its own version of that copy (linked back to the copy of course). -as you say, the specific project defines what is different from the GPR where necessary.

So I'd be linking a project A requirement back to the original GPR requirement where appropriate.

It may also be that project B links its own copy of the requirement back to the original GPR requirement.

But I wouldn't be linking cross-project as it were (only via the GPR original requirement).

 

Would that make sense ?

 

Re: Nested Projects
llandale - Thu Sep 26 12:02:23 EDT 2013

Dartguru - Thu Sep 26 07:16:07 EDT 2013

So I'd be looking at:-

Project X - contains Generic Product Requirements (GPR) module(s) (either at the same level or within a GPR folder), and folders for projects A,B,C and so on.

I could copy GPR requirements to any of project A,B,C etc linked back to the GPR original. It may be that the GPR requirement I have copied is only a "starting point" and the project itself derives its own version of that copy (linked back to the copy of course). -as you say, the specific project defines what is different from the GPR where necessary.

So I'd be linking a project A requirement back to the original GPR requirement where appropriate.

It may also be that project B links its own copy of the requirement back to the original GPR requirement.

But I wouldn't be linking cross-project as it were (only via the GPR original requirement).

 

Would that make sense ?

 

Yes, but I wonder if project A comes up with it's own specific requirement (which is not General), and also Project B has the same requirement.  Do you want to know that they have the same requirement?  If analysis shows that that ReqA should be come ReqA+, would you want to notify the B folks of the analysis?

Gets hairy.

-Louie